Conversation
The examples in the docs use bare URLs with the `Request` constructor like `new Request('/request-to-handle')` but in Node, this constructor requires a full URL with a host, otherwise a `TypeError: Failed to parse URL from /request-to-handle` will be thrown.
But this is not a complete fix, we need to explain where the `HOST_NAME` constant will come from and what it should contain.
Opening this PR to start the discussion.
|
I think I would prefer using |
bluwy
changed the title
bluwy
changed the title
|
I guess we should also clarify that the host part will be overwritten by the environment (so that it can send that request to the runtime where the module runner lives). |
|
I feel the issue is that just the doc here is the vague since |
|
It's not uncommon to change routing rules for different origins (free.example.com might lack some of the routes on paid.example.com) but I suppose it can be considered not critical for dev. I left a comment on the FetchableDevEnvironment proposal some months ago suggesting something like "proxyable" instead of (or in addition to) "fetchable" could be more useful, because I'd expect most of the time the transport to be HTTP and proxying can do things that fetch can't (like keeping the original host header). I'll leave another comment in that discussion. For now, I changed HOST_NAME to example.com. |
4 participants
The
FetchableDevEnvironmentexamples in the docs use bare URLs with theRequestconstructor likenew Request('/request-to-handle')but in Node, this constructor requires a full URL with a host, otherwise aTypeError: Failed to parse URL from /request-to-handlewill be thrown.But this is not a complete fix, we need to explain where theUPDATE: Changed host name toHOST_NAMEconstant will come from and what it should contain. If we don't care about the actual host, a simplehttp://example.comwill work but it would be confusing and require some explanation at least.http://example.com.Opening this PR to start the discussion.